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Abstract 

Formal capture and analysis of the required behav- 
ior of control systems have many advantages. For in- 
stance, it encourages rigorous requirements analysis, 
the required behavior is unambiguously defined, and 
we can assure that various safety properties are satis- 
fied. Formal modeling is, however, a costly and time 
consuming process and if one could reuse the formal 
models over a family of products, significant cost sav- 
ings would be realized. 

In an ongoing project we are investigating how to 
structure state-based models to achieve a high level 
of reusability within product families. In this paper 
we discuss a high-level structure of requirements mod- 
els that achieves reusability of the desired control be- 
havior across varying hardware platforms in a prod- 
uct family. The structuring approach is demonstrated 
through a case study in the mobile robotics domain 
where the desired robot behavior is reused on two di- 
verse platforms — one commercial mobile platform and 
one build in-house. We use our language RSML ~ e to 
capture the control behavior for reuse and our tool 
NIMBUS to demonstrate how the formal specification 
can be validated and used as a prototype on the two 
platforms. 

Keywords: Requirements, Formal Models, Re- 
quirements Reuse, Control Systems, RSML _e 
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1 Introduction 

Reuse of software engineering artifacts across 
projects has the potential to provide lar ge cost savings. 
Traditionally, the research in the reuse community has 
focused on how to construct reusable software com- 
ponents, and how to classify and organize these com- 
ponents into libraries where they can be retrieved for 
use in a particular application. We know, however, that 
coding errors are not the main source of problems and 
delays in a software project; incomplete, inconsistent, 
incorrect, and poorly validated requirements are the 
primary culprit [4], Tlius, we hypothesize that reuse 
of requirements in conjunction with reuse of design 
and code will provide greater benefits in terms of both 
cost and quality, hi this paper we present an approach 
to structuring formal requirements models for control 
systems that make the control requirements reusable 
across platforms where the hardware (sensors and ac- 
tuators) may vary. We also illustrate the structuring 
approach with an example from the mobile robotics 
domain. 

The beginnings of our approach is a high-level re- 
quirements structuring technique based on the rela- 
tionship between system requirements and the soft- 
ware specification. We developed this structuring 
technique to enable a software development approach 
we call specification-based prototyping [23] where 
the formal requirements model is used as a prototype 
(possibly controlling the actual hardware — hardware - 
in-the-loop-simulation) during the early stages of a 
project. Here we present how this structuring ap- 
proach also enables reuse of the high-level require- 
ments across members of a product family with vari- 
abilities in the hardware components. The approach is 



demonstrated via a case study in the mobile robotics 
domain where the desired robot behavior is reused on 
two diverse platforms — one commercial mobile robot 
and one built in-house. We use our language RSML -e 
to capture the desired control behavior for reuse and 
our tool Nimbus to demonstrate how the formal spec- 
ification can be validated and used as a prototype on 
both platforms. 

The rest of the paper is organized as follows. Sec- 
tion 2 describes related work on requirements reuse 
and product families. Then, Section 3 describes our 
approach to structuring the high-level system require- 
ment and the software specification. Section 4 de- 
scribes the mobile robotics platforms that we are using 
as the case study in the paper and presents a simple 
analysis of their commonalities and variabilities. The 
requirements of the mobile platforms in the family are 
presented in Section 5. The refinement of these system 
requirements to a software specification is presented in 
Section 6. hr this section we also show how the sys- 
tem requirements at e reused across the members of the 
product family. Finally, Section 7 presents a summary 
and conclusion. 

2 Related Work 

Tire foundations for reuse of can be traced back to 
the early work on program structure and modularity 
pioneered by David Parnas and others [3, 20, 21, 22]. 
This work establishes the basis for reuse: the concept 
of a self contained module with well-defined inter- 
faces. Nevertheless, the guidelines for how to encap- 
sulate and structure a model (in this case implemen- 
tations) for reuse is not sufficiently addressed in this 
early work. Tlius, subsequent research in the field of 
software reuse seeks to further define and provide ad- 
ditional tools and techniques for reuse. 

In the area of requirements reuse, Lam et ai pro- 
vides some guidance on specific techniques which can 
be used by organizations to introduce requirements 
reuse into their software process [15]. In addition, 
Lam addressed requirements reuse in the context of 
component-based software engineering [14]. Our area 
of interest is more in structuring of specifications to 
achieve reuse; nevertheless, this work presents some 
ideas about how to package and specify generic re- 
quirements and how to factor requirements into plug- 
gable requirements parts [15], Of particular interest is 
the relationship of their work to the product families 
work being done at Lucent Technologies [2, 24], 

Product family engineering is related to the work 
presented in this paper; in particular, the FAST (Fam- 
ily Oriented Abstraction, Specification and Transla- 


tion) approach is of interest. FAST provides a pro- 
cess for how to identify commonalities and variabili- 
ties across a product family. This commonality analy- 
sis can then be used to provide domain specific devel- 
opment tools that will greatly reduce the development 
costs for later generations of the product family. FAST 
does not explicitly address the structuring of product 
requirements. The FAST concepts of the domain anal- 
ysis and the commonality analysis can, however, be di- 
rectly applied to our work with formal specifications; 
FAST provided some of the inspiration for the work 
presented here. 

Little work has been done on how to structure and 
develop a formal specification in a language such as 
RSML -e . One notable exception is the CoRE method- 
ology [5, 6, 7] developed by the Software Productivity 
Consortium. CoRE includes much useful information 
on how to perform requirements modeling in a semi- 
formal specification language (similar to the formal 
SCR defined at the Naval Research Laboratory [12]). 
Even so, the structuring mechanism proposed in the 
CoRE guidebook is based on the physical structure of 
the system as well as which pieces of the system that 
are likely to change together — these two (often con- 
flicting) structuring mechanisms may or may not be 
beneficial to reuse. Furthermore, the way in which 
the structuring techniques achieve reuse is not spec- 
ified in the guidebook — reuse is not specifically ad- 
dressed. Our work is based on many ideas similar to 
those found in CoRE, but we have extended and re- 
fined these ideas to address structuring of state-based 
requirements models to achieve (1) conceptual clar- 
ity, (2) robustness in the face of the inevitable require- 
ments changes to which every project is subjected, (3) 
robustness of the requirements as hardware evolves, 
and (4) reuse of models as well as V&V results. 

3 Structuring 

hr our work we are primary interested in safety crit- 
ical applications; that is, applications where malfunc- 
tion of the software may lead to death, injury, or en- 
vironmental damage. Most, if not all, such systems 
are some form of a process control system where the 
software is participating in the control of a physical 
system. 

3.1 Control Systems 

A general view of a software controlled system can 
be seen in the center of Figure 1 . This model con- 
sists of a process, sensors, actuators, and a software 
controller. The process is the physical process we are 
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function OUT maps OUTPUT to CON. The behavior 
of the software controller is defined by the SOFT rela- 
tion that maps INPUT to OUTPUT. 

The requirements on the control system are ex- 
pressed with the REQ relation; the system require- 
ments shall always be expressed in terms of quanti- 
ties in the physical world. To develop the control soft- 
ware, however, we are interested in the SOFT relation. 
Titus, we must somehow refine the system require- 
ments (the REQ relation) into the software specifica- 
tion (the SOFT relation). 

3.2 Structuring SOFT 


Figure 1. A traditional process control 
model (center) and how it is captured 
with the four variable model 


attempting to control. The sensors measure physical 
quantities in the process. These measurements are pro- 
vided as input to the software controller. The con- 
troller makes decisions on what actions are needed 
and commands the actuators to manipulate the pro- 
cess. The goal of the software control is to maintain 
some properties in the physical process. Thus, un- 
derstanding how the sensors, actuators, and process 
behave is essential for the development and evalua- 
tion of correct software. The importance of this sys- 
tems view has been repeatedly pointed out in the liter- 
ature [19, 17, 12], 

To reason about this type of software controlled 
systems, David Parnas and Jan Madey defined what 
they call the four-variable model (outside square of 
Figure 1) [19], In this model, the monitored vari- 
ables (MON) are physical quantities we measure in 
the system and controlled variables (CON) are phys- 
ical quantities we will control. The requirements on 
the control system are expressed as a mapping (REQ) 
from monitored to controlled variables. For instance, 
a requirement may be that “in case of a collision, the 
robot must back up and turn 90 degrees left’.’ Natu- 
rally, to implement the control software we must have 
sensors providing the software with measured values 
of the monitored variables (INPUT), for example, an 
indication if the robot has collided with an obstacle. 
The sensors transform MON to INPUT through the IN 
relation; thus, the IN relation defines the sensor func- 
tions. To adjust the controlled variables, the software 
generates output that activates various actuators that 
can manipulate the physical process, for instance, a 
means to vary the speed of the robot. The actuator 


The IN and OUT relations are determined by the 
sensors and actuators used in the system. For example, 
to determine if the robot has collided with an obstacle 
we may use a bumper with micro-switches connected 
to a digital input card. Similarly, to control the speed 
of a robot we may use a digital to analog converter 
and DC motors. Armed with the REQ relation, the IN 
relation, and the OUT relation we can derive the SOFT 
relation. The question is, how shall we do this and how 
shall we structure the description of the SOFT relation 
in a language such as RSML~ e ? 

As mentioned above, the system requirements 
should always be expressed in terms of the physical 
process. These requirements will most likely change 
over the lifetime of the controller (or family of simi- 
lar controllers). The sensors and actuators are likely to 
change independently of the requirements as the con- 
troller is reused in different members of a family or 
new hardware becomes available; thus, all three rela- 
tions, REQ, IN, and OUT, are likely to change over 
time. If either one of the REQ, IN, or OUT rela- 
tions change, the SOFT relation must be modified. 
To provide a smooth transition from system require- 
ments (REQ) to software specification (SOFT) and to 
isolate the impact of requirements, sensor, and actu- 
ator changes to a minimum, the structure of the soft- 
ware specification SOFT should be based heavily on 
the structure of the REQ relation [18, 23], 

We achieve this by splitting the SOFT relation into 
three pieces, IN -1 , OUT -1 , and SOFT hj.jq (Figure 2). 
IN -1 takes the measured input and reconstructs an es- 
timate of the physical quantities in MON. The OUT -1 
relation maps the internal representation of the con- 
trolled variables to the output needed for the actuators 
to manipulate the actual controlled variables. Given 
the IN -1 and OUT -1 relations, the SOFTa^q rela- 
tion will now be essentially isomorphic to the system 
requirements (the REQ relation) and. thus, be robust if 
it is reused on a new platform (manifested as changes 
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Figure 2. The SOFT relation can be split 
into three composed relations. 


in the IN and OUT relations). Such changes would 
only effect the IN -1 and OUT -1 portions of the soft- 
ware specification. Tims, the str ucturing approach out- 
lined in this section will makes the SOFT req portion 
of the software specification reusable over members of 
a product family exhibiting the same high-level behav- 
ior. 

4 Mobile Robotics Platforms 

When evaluating our work, we wanted to find a do- 
main were a variety of similar platforms could be con- 
structed on a university budget in a timely and cost 
effective manner. Furthermore, we wanted this do- 
main to be realistic — with the inclusion of noisy sen- 
sors and actuators and the possibility of complex sen- 
sor fusion and error detection. The mobile robotics 
domain seemed ideally suited for these needs. 

The mobile robotics platforms that we are using in 
our research range in size from about the size of the 
Mars Pathfinder to a small lego-bot. The robots have 
a limited speed, and can operate either autonomously 
(via a radio modem or radio Ethernet) or via a tether 
cable going to a personal computer. The robotics plat- 
forms come from various vendors and have a wide va- 
riety of sensors and actuators available. 

The platforms that are discussed in this paper are 
shown in Figure 3 1 . One platform, the Pioneer [1], 
is built and sold by ActivMedia, Inc. The Pioneer in- 
cludes an array of sonar sensors in the front and sides 
that allow it to detect obstacles. To detect collisions, 
the Pioneer monitors its wheels and signals a collision 
when the wheels stall. The Pioneer includes an exten- 
sive control library called Saphira. The Pioneer is con- 
trolled by a radio modem that plugs in to the personal 
computer’s serial port. Saphira manages the commu- 
nication over the radio modem. Saphira is capable of 
implementing complex rule -based control functions; 
however, in our work we are using only the simplest 
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Figure 3. A picture of the robotic plat- 
forms used in this paper 


of Saphira functions that allow us nearly direct access 
to the sensors and actuators. Nevertheless, the level of 
abstraction presented by the Saphira library is signif- 
icantly higher than on the other platform in this case 
study: the lego-bot. 

The lego-bot is a smaller platform built from Lego 
building blocks and small motors and sensors. The 
lego-bot uses a tank-like hack locomotion system and 
has infrared sensors for range detection. The lego-bot 
is controlled via a tether to the robot from the per- 
sonal computer. This tether is connected to a data- 
acquisition card and the software specification for the 
lego-bot behavior must directly manage the low-level 
voltages and signal necessary to control the robot; 
there is very little support for the actuators and sen- 
sors. 

Despite the significant difference between the plat- 
forms, we wanted them to exhibit nearly identical vis- 
ible behaviors; the only difference would be in the 
hardware determined speed of the robot’s movements. 
Therefore, the visible behavior (the REQ relation) for 
each robot is the same. Note that we are not addressing 
non-behavioral requirements such as power consump- 
tion and weai' and tear of hardware components in our 
discussions of reuse. We have focused solely on the 
behavior captured in the requirements. 

5 The REQ relation 

The first step in a requirements modeling project is 
to define the system boundaries and identify the mon- 
itored and controlled variables in the environment. In 
this paper we will not go into the details of how to 


scope the system requirements and identify the mon- 
itored and controlled variables — guidelines to help 
identify monitored and controlled variables have been 
discussed in numerous other places [6, 13, 18], Here it 
suffices to say that the monitored and controlled vari- 
ables exist in the physical system and act as the in- 
terface between die proposed controller (software and 
hardware) and the system to be controlled. 

For the mobile robots, the goal was to construct a 
simple reactive control behavior tiiat would cause the 
robot to explore its environment. To accomplish this 
objective, the robot must be able to perform several 
tasks: 

• If the robot detects an obstacle, it shall attempt to 
avoid it. 

• If the robot collides widi an obstacle, it shall at- 
tempt to recover from die collision and continue 
exploration. 

• In die absence of a collision or obstacle, the robot 
shall proceed to move forward at full speed. 

In this case study, we wanted all robots of the prod- 
uct family to exhibit the same exploratory behavior. To 
capture diis behavior we must discover monitored and 
controlled variables in the environment diat will allow 
us to build the formal model, hi addition, while eval- 
uating candidates for monitored and controlled vari- 
ables we must keep in mind that the REQ model shall 
apply to all members of the product family. 

We identified a robot’s speed and heading as con- 
trolled variables. Speed ranges from 0 to 100 and can 
be mapped into a speed for each family member using 
the maximum speed of the particular robot. Heading 
ranges from -180 to 180 and indicates the number of 
degrees that the robot may have to turn to avoid an ob- 
stacle. 

We identified CollisionDetected, Range, and Ob- 
stacleOrientation as monitored variables. The Colli- 
sionDetected variable is simply a Boolean value which 
is true when there is a collision and false otherwise. 
The Range variable is the distance from the robot to 
the nearest obstacle and the ObstacleOrientation de- 
notes whether the obstacle is straight ahead, or on the 
right or left of the robot. These variables clearly reside 
in the system domain and are sufficient to model the 
desired behavior. If the monitored and controlled vari- 
ables are chosen appropriately, the specification of the 
REQ relation will be focused on the issues which are 
central to the requirements on the system. 

Since our work is based around a modeling lan- 
guage called RSML -6 (Requirements State Machine 
Language without events), a state-based language suit- 
able for modeling of reactive control systems, we pro- 


vide a short introduction to the notation before we con- 
tinue with a discussion of the REQ relation for the mo- 
bile robots. 

5.1 Introduction to RSML -6 

RSML -6 is based on the language Requirements 
State Machine Language (RSML) developed by the 
Irvine Safety Research group under the leadership of 
Nancy Leveson [17], RSML -6 is a refinement of 
RSML and is based on hierarchical finite state ma- 
chines and dataflow languages. Visually, it is some- 
what similar to David Harel’s Statecharts [10, 8, 9], 
For example, RSML -6 supports parallelism, hierar- 
chies, and guarded transitions. The main differences 
between RSML -6 and RSML are the addition in 
RSML -6 of rigorous specifications of the interfaces 
between the environment and the control software, 
and file removal of internal broadcast events. The re- 
moval of events was prompted by Nancy Leveson’s 
experiences with RSML and a new language called 
SpecTRM-RL that she has evolved from RSML. These 
experiences have been chronicled in [16], 

An RSML -6 specification consists of a collection 
of state variables, HO variables, interfaces, functions, 
macros, and constants, which will be briefly discussed 
below. 

In RSML -6 , the state of the model is the values 
of a set of state variables, similar to mode classes in 
SCR [12]. These state variables can be organized in 
parallel or hierarchically to describe the current state 
of tlie system. Parallel state variables are used to rep- 
resent the inherently parallel or concurrent concepts in 
the system being modeled. Hierarchical relationships 
allow child state variables to present an elaboration of 
a particular parent state value. Hierarchical state vari- 
ables allow a specification designer to work at multiple 
levels of abstraction, and make models simpler to un- 
derstand. 

Lor example, consider the behavioral requirements 
for our mobile robots outlined in the introduction to 
tins section. The state variable hierarchy used to model 
the requirements on tins system can be represented as 
in Ligure 4. Tins representation includes both parallel 
and hierarchical relationships of state variables: Fail- 
ure and Normal are two parallel state variables and 
Robot .Recover Action is a child of Normal. 

Next state functions in RSML -6 determine the 
value of state variables. These functions can be orga- 
nized as transitions or conditional assignments. Con- 
ditional assignments describe under winch conditions 
a state variable assumes each of its possible values. 
Transitions describe the condition under which a state 
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Figure 4. The REQ relation state hierarchy 


variable is to change value. A transition consists 
of a source value, a destination value, and a guard- 
ing condition. The two state function types are log- 
ically equivalent; mechanized procedures exist to en- 
sure that both types of functions are complete and con- 
sistent [11]. 

The next state functions are placed into a partial 
order based on data dependencies and the hierarchi- 
cal structure of the state machine. State variables are 
data-dependent on any other state variables, macros, 
or I/O variables that are named in their transitions or 
condition tables. If a variable is a child variable of 
another state variable, then it is also dependent on its 
parent variable. The value of the state variable can be 
computed after the items on which it is data-dependent 
have been computed. For example, the value of the 
Robot Avoid Action state variable would be computed 
after the Obstacle -Distance state variable because the 
action to take is dependent upon the range of the ob- 
stacle. 

Conditions are simply predicate logic statement 
over the various states and variables in the specifica- 
tion. The conditions are expressed in disjunctive nor- 
mal form using a notation called AND/OR tables [17] 
The far-left column of the AND/OR table lists the logi- 
cal pln ases. Each of the other columns is a conjunction 
of those phr ases and contains the logical values of the 
expressions. If one of the columns is true, then the ta- 
ble evaluates to true. A column evaluates to true if all 


of its elements match the truth values of the associated 
columns. An asterisk denotes “don’t care.” Examples 
of and/or tables can be found later in this section and 
in the next section. 

HO Variables in the specification allow the analyst 
to record the monitored variables (MON) or values 
reported by various external sensors (INPUT) (in the 
case of input variables) and provide a place to cap- 
ture the controlled variables (CON) or the values of 
the outputs (OUTPUT) of the system prior to sending 
them out in a message (in the case of output variables). 

To further increase the readability of the specifi- 
cation, RSML~ e contains many other syntactic con- 
ventions. For example, RSML~ e allows expressions 
used in the predicates to be defined as functions and 
familial' and frequently used conditions to be defined 
as macros. Finally, RSML -e requires rigorous speci- 
fication of interfaces between the environment and the 
model. 

5.2 REQ Relation Overview 

Due to space constraints, the entire model of the 
REQ relation cannot be given in this paper and we will 
focus on an illustrative subset. Figure 4 shows that the 
REQ relation definition at the top level is split between 
two state variables: Failure and Normal. The Failure 
state variable encapsulates the failure conditions of the 
REQ relation, whereas the Normal state variable de- 




scribes the how the robot transitions between the vari- 
ous high-level behaviors discussed at the introduction 
to this section (obstacle avoidance, collision recovery, 
etc.). For the reminder of our discussion of REQ, we 
will focus on the Normal state variable where this as- 
pect of the requirements is captured (Figure 5). 

The Normal variable defaults to the startup value. 
This allows the specification to perform various ini- 
tialization tasks and checks before the main behav- 
ior takes over. The first transition in Figure 5 states 
that after two seconds, the specification will enter die 
Cruise -Forward, state. 

The next two transitions govern die way that 
the Normal state variable can change from the 
Cruise-Forward value. If a collision is detected, then 
the state variable changes to the Collision .Recover 
state. If an obstacle is detected, dien the specifica- 
tion will enter die Avoid .Ob stacle state. Odierwise, 
the value of the Normal state variable will remain un- 
changed. 

If a collision or obstacle is detected, die machine 
needs to begin the Cruise .Forward behavior when die 
avoidance/recovery action has been completed. We ac- 
complished this in die mobile robotics specification by 
providing a “done” state in each of the sub-behaviors. 
This is illustrated by the fifth and sixdi transitions in 
Figure 5. 

Finally, it is also possible to transition from 
Avoid. Obstacle directly to Collision Recover if, for 
example, the robot hits an undetected obstacle; this 
case is covered by the final transition in Figure 5. 

Given this definition of the REQ relation high- 
level behaviors, the definitions of the sub-behaviors 
can be constructed in a similar and straightforward 
manner. For example, if the robot hits an obsta- 
cle, it will adempt to back up, turn, and then pro- 
ceed forward again. This behavior is specified in 
the Robot Recover Action state variable by having the 
variable cycle though the values Backward, Turn, and 
finally Done. 

6 The SOFT relation 


|State Variable! 

Normal 

Location: Reactive_Control 


Transition: Startup — ► Craise_Forward 


Condition: 



TIME > 2 s 

T 


..Failure IN_STATE Ok 

T 

Transition: Cmise_Forward— ►Collision_Recover 


Condition: 



CollisionDetectedMacro() = TRUE 

T 


..Failure IN_STATE Ok 

T 

Transition: Cruise_Forward — ►Avoid_Obstacle 


Condition: 



ObstacleDetectedMacro() = TRUE 

T 


CollisionDetectedMacroO = FALSE 

T 


..Failure IN_STATE Ok 

T 

Transition: Collision_Recover — ►Cruise_Forward 


Condition: 



Prev_Step(..Robot_Recover_Action IN_STATE Done) 

T 


..Failure IN_STATE Ok 

T 

Transition: Avoid_Obstacle — ► Cruise_Forward 


Condition: 



Prev_Step(..Robot_Avoid_Acrion IN_STATE Done) 

T 


..Failure IN_STATE Ok 

T 


Transition: Avoid_Obstacle — ► Collision_Recover 

Condition: 


CollisionDetectedMacroO = TRUE 

T 

..Failure IN_STATE Ok 

T 


When refining the specification from REQ to Figure 5. The definition of the Normal 

SOFT, we select the sensors and actuators that will state variable 

supply the software witii information about the envi- 
ronment, that is, we must select the hardware and de- 
fine the IN and OUT relations for each platform. Con- 
sequently, we will also need to define the IN -1 and 
OUT -1 for each platform. We do not have the space 
to discuss the IN, OUT, IN -1 , and OUT -1 for every 
monitored and controlled variable. Instead, we will 
focus our discussion on two areas where the Pioneer 









and the lego-bot presented illustrative and challenging 
differences. 

6.1 Obstacle Detection — 

Sonar versus Infrared 

As members of the mobile robot product family that 
we specified in Section 5. both the Pioneer and the 
lego-bot have the ability to sense the distance to ob- 
jects in their surroundings. Distance sensors typically 
function by emitting some sort of signal (for example, 
a sound in the case of sonar) and then measuring the 
amount of time between the emission of the signal and 
its being received back at the sensor. Given how fast 
the signal can travel, the distance to the closest object 
can be determined. Although the distance sensors may 
be somewhat similar in their operation, different sen- 
sors provide very different accuracies and ranges. For 
example, a laser range finder is far more accurate and 
has much less noise than the sonar sensors. 

The Pioneer uses sonar sensors and the Saphira 
software package to accomplish obstacle detection 
whereas the lego-bot uses a set of simple infrared 
range finders. This significant difference in the type 
of sensors as well as differences in the number and 
placement of the sensors leads to two quite different IN 
relations. The differences of the IN relations necessi- 
tate different IN -1 in the computation of the estimated 
value of the Range monitored quantity. 


|Function| 

PT ransformRange 


Type: INTEGER 
Parameters: 

ilnRange IS INTEGER 


:= OIF 


ilnRange <= 0 

F 

T 

ilnRange > 700 

T 

F 


:= iInRange/7 IF 


ilnRange > 0 

T 

ilnRange <= 700 

T 


Figure 7. IN 1 Range for the Pioneer 

The difference between the SOFT relations for the 
two platforms (with respect to the range to obstacles) 
can be encapsulated in a function which transforms the 
input variables from the range sensors to estimates of 
the monitored quantity Range. The computation of 


[Function! 

LT ransformRange 


Type: INTEGER 
Parameters: 

ilnRange IS INTEGER 


:= OIF 



Figure 8. IN -1 Range for the lego-bot 


IN -1 for the Pioneer is pictured in Figure 7 and for 
the lego-bot is in Figure 8. For the Pioneer, the sonar 
inputs range from 0 to 700 and must be scaled appro- 
priately to a number between zero and 100. 

For the lego-bot, the transformation is more com- 
plex. Both the sonar and the infrared distance sensors 
have a certain range close to the sensor where the sig- 
nals cannot be used for range detection (in the case of 
the sonars, the signals that are emitted bounce back to 
the sensor too fast for the sensor to detect). Titus, the 
sensor will report that no obstacle is present when, in 
fact, an obstacle is very close. In the case of the Pi- 
oneer, this problem is handled by the Saphira library. 
For the lego-bot, however, the RSML~ e specification 
must include a minimum tlueshold as well as a scaling 
factor for the maximum values. In our case, readings 
below 200 from the infrared sensor cannot be trusted 
and we simply treat any reading below 200 as if the 
distance is 0, indicating that no obstacle has been (or 
can be) detected (Figure 8). 

Titus, we have shown that even though the sensors 
and the way in which we have access to the sensors 
differs widely between the Pioneer and the lego-bot, 
we can still use the same SOFTr^q model for both 
robot platforms, hi this way, we make the high-level 
behavior robust and reusable in the face of changes in 
the range finder. 

6.2 Speed — 

Saphira versus Pulse Modulation 

The previous section focused on platform depen- 
dent variabilities in the IN and IN -1 relations. The 
Pioneer and the lego-bot have more significant differ- 








Figure 6. The state machine tor the lego-bot 


ences in the way that they control their propulsion and 
in their steering systems (the OUT and OUT -1 rela- 
tions). 

The Pioneer’s Saphira library provides a high-level 
control of the Pioneer’s motors so that the specifica- 
tion for SOFT on the Pioneer platform is very simi- 
lar to REQ. The transformation of the desired speed 
performed in OUT -1 for the Pioneer (Figure 9) only 
requires some minor scaling with respect to the Pio- 
neer’s maximum speed. The result of this transforma- 
tion can then be directly sent to the Pioneer platfonn 
and Saphira will control the hardware to achieve the 
desired speed. 


|Function| 

PT ransformConSpeed 


Type: INTEGER 
Parameters: 

iConSpeed IS INTEGER 


:= OIF 



iConSpeed = 0 

□ 

:= (PMaxSpeed * iConSpeed)/100 IF 


iConSpeed = 0 

□ 


Figure 9. OUT -1 Speed for the Pioneer 


|State Variable^ 

MotorPulseSlatus 

Location: ..MotorOn 

Transition: Off® On 
Condition: 


TIME >= PREV STEP (..MotorPulseStatus TIME_ENTERED Off) + 
LMotorPWMTimeOut(Heading, ConSpeed) 

T 

PREV_STEP(.. MotorPulseStatus IN_STATE Off) 

T 


Transition: On ® Off 
Condition: 


TIME >= PREV_STEP(.. MotorPulseStatus TTME_ENTERED On) + LPWMOnTimeOut 

T 

PREV_STEP(.. MotorPulseStatus IN_STATE On) 

T 

ConSpeed =100 

F 


:= On 

Condition: 

I ConSpeed = 100 Tr 


Figure 10. The part of OUT -1 for the 
Lego-bot that performs the pulsing on 
the motors 


On the other hand, the OUT 1 specification for the 
speed of the lego-bot is significantly more complex. 






This is because the SOFT relation for the lego-bot 
must control the motors directly with low-level hard- 
ware signals. The speed of the lego-bot is controlled 
by a technique called pulse-width modulation of the 
DC motors: the speed of the motors is determined by 
the length of tune which passes between pulses of cur- 
rent applied to the motor. Therefore, the SOFT specifi- 
cation cannot simply output the speed value with some 
transformation applied; instead, we must use die com- 
puted value for the controlled variable Speed to deter- 
mine the pulse width for the motors and then output 
the pulses accordingly; die motors will then provide 
enough propulsion to move the lego-bot at die desired 
speed. 

This control strategy necessitates a more complex 
OUT -1 relation for the desired speed; the OUT -1 re- 
lation can no longer be a simple function — in diis case 
we need to add an additional state machine. To model 
the pulse modulation we add a state variables to the 
SOFT specification so that die machine can output the 
required pulses. These additions are shown in Fig- 
ure 6. The MotorPulseStatus state variable is the part 
of the OUT -1 specification diat determines the pulse 
width. Figure 10 shows die definition of this state vari- 
able. 

A key component of the pulse-width modulation is 
the LMotorPWMTimeOut function which determines 
the length of time to pulse the motors (Figure 11). No- 
tice that because of the lego-bot ’s tank- track propul- 
sion system, the motors must be pulsed both in the case 
of a turn and in the case that the robot is moving for- 
ward. Thus, the LMotorPWMTimeOut function takes 
as parameters the controlled variables for speed and 
heading and produces the correct timeout values. 

The values for the pulse intervals were were cho- 
sen by running experiments to determine which pulse 
interval would achieve which speed. We have, there- 
fore, encapsulated these constants so that if we were to 
change motors on the lego-bot in the future we could 
simply change the constants rather than having to re- 
visit the pulse- width modulation process. 

Tlius, despite the fact that the Pioneer and the lego- 
bot differ significantly in the way that the motors are 
controlled, the SOFT req relation can again be reused 
across the platforms. Furthermore, changes in the 
REQ relation (and analogous changes to SOFT req) 
will be independent of changes in the OUT and 
OUT -1 relations. 

7 Conclusions 

This paper describes how structuring the require- 
ments based on the relationship between the system 


|FunctioH 


LMotorPWMTimeOut 


Type: TIME 
Parameters: 

• iHeading IS INTEGER 
iConSpeed IS INTEGER 


:= LSlowPWMOffTimeOut IF 


iHeading = 90 

T 

F 

F 

iHeading = -90 

F 

T 

F 

iConSpeed = 25 

F 

F 

T 


:= LMidPWMOffTimeOut IF 


iHeading = 45 

T 

F 

F 

F 

iHeading = -45 

F 

T 

F 

F 

iConSpeed = 50 

F 

F 

T 

F 

iConSpeed = -50 

F 

F 

F 

T 


:= LFastPWMOffTimeOut IF 


iHeading = 20 

T 

F 

F 

iHeading = -20 

F 

T 

F 

iConSpeed = 75 

F 

F 

T 


:=0 s IF 


iConSpeed = 100 I T 


Figure 11. The timeout function for 
pulse-width modulation on the Lego-bot. 






requirements and the software specification can lead 
to benefits in terms of maintainability and reusability. 
Specifically, we describe a technique for structuring 
high-level requirements for reuse in the face of hard- 
ware changes. 

From file four variable model for process control 
systems, we have described how the REQ relation can 
be refined to file SOFT relation while maintaining a 
separation between the part of SOFT which is related 
to REQ ( SOFT rjcq ) and file parts of SOFT which han- 
dle file particular sensors and actuators in the system 
design (IN -1 and OUT -1 ). This allows us to sepa- 
rate changes in the requirements from sensor and ac- 
tuator changes and achieve better maintainability and 
reusability. 

This teclmiques was demonstrated on a case study 
in file mobile robotics domain using two quite differ- 
ent robots. One robot is commercially produced and 
is equipped with a rich control library that provides 
many complex control functions, for example, travel- 
ing at a requested speed. The other robot was build in- 
house from Lego building blocks and off-the-shelf mo- 
tors and sensors. This robot is controlled completely 
by file software specification in RSML -e through our 
Nimbus toolset. 

We demonstrated the usefuhiess of the structur- 
ing approach by reusing the high-level requirements 
(REQ) across a (currently quite small) family of mo- 
bile robots. Nevertheless, there are numerous issues 
left to address. In the future, we plan to define more 
complex control behaviors and investigate how indi- 
vidual behaviors (or operational modes) can be suc- 
cessfully reused. 
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